Instead, handle streaming queue in a new thread (which serialises writes to the connection socket, and handlers errors such as IOError, Errno::EPIPE triggering callbacks.

This is so that the server's request thread (ie Puma) can be quickly returned to the pool.
Servers like Falcon (fibers instead of threads) should not have this problem, but they should still work fine with this (they will spawn an extra fiber, but that should be cheap).

Possible issues:

This change decouples the server's thread pool from Datastar's streaming threads, which ATM are unbounded (an app with long-lived streams could potentially spawn thousands of threads even if the server is configured with a limited pool.

This can be problematic, because:

* The server can run out of resourced
* If the streams rely on services such as database connections, they could quickly drain those connection pools.

Possible solution: provide configuration for a separate, Datastar-specific thread-pool so that it can be tweaked as per available resources (such as database pools)